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ABSTRACT 


This  report  is  a description  of  the  pilot  version 
of  the  ASW  Mission  Effectiveness  computer  program.  Sections 
I and  ^ discuss  the  purpose  of  the  program  and  the  simulation 
model  for  the  reader  without  a conqjuter  programming  background. 
Section  is  a description  of  the  program  organization  for  a 
reader  with  such  a background.  This  is  the  final  report  cover- 
ing activities  performed  under  WPll-7.  The  interim  report 
(TRG  Report  No.  023-TM-66-18)  gave  a cursory  description  of 
this  program  at  a late  stage  in  the  ke3rpunching  phase  of  the 
various  decks  which  constitute  this  program.  Many  revisions 
and  corrections  have  been  made  since  then.  This  final  report 
describes  the  program  at  an  early  stage  of  the  debugging  and 
testing  phase  (WPll-8).  The  initial  results  from  this  program 
will  be  described  in  the  next  report,  the  first  reoort  cover- 
ing activities  performed  under  WPll-8. 
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SECTION  I 
INTRODUCTION 

The  ASW  mission  effectiveness  computer  program  (MEP) 
simulates  a complex  ASW  action  involving  ships,  submarines, 
aircraft,  and  their  respective  sensors  and  weapons.  Its  pur- 
pose is  to  produce  a narrative  of  events  which  will  show  the 
effect  of  sonar  system  performance  on  the  accomplishment  of  a 
mission.  This  performance,  as  well  as  the  performances  of  the 
other  sensors,  platforms,  and  weapons,  are  either  input  to  the 
computer  program  or  stored  within  the  program  in  the  form  of 
tables. 

MEP  is  designed  to  simulate  tactical  situations 
involving  25  to  30  units,  e.g.,  a dozen  or  so  convoy  ships, 
a screen  of  5 or  6 destroyers,  several  aircraft,  and  submarine 
adversaries.  The  number,  type,  and  initial  disposition  of 
these  units  is  set  up  by  input.  The  tactical  doctrine  which 
controls  the  decisions  of  the  commanding  officers  during  the 
course  of  the  action  is  input  in  a language  designed  for  this 
purpose.  Decisions  are  made  on  the  basis  of  information 
available  to  commanding  officers  from  their  sensors.  The 
decisions  made  cause  certain  actions  to  take  place,  e.g.,  a 
ship  maintains  or  changes  course,  sends  or  receives  a message, 
continues  or  alters  the  sonar  operating  procedure,  etc. 

Actions  produce  new  information  for  the  next  set  of  decisions. 
Thus,  MEP  simulates  a closed-loop  informat  ion- feedback  sys- 
tem where  the  information  available  (because  of  sensor  per- 
formance) controls  the  decisions  that  affect  the  information 
available  (because  of  the  actions  caused  by  the  decisions). 

MEP  is  organized  around  the  functions  which  are 
relevant  to  the  purpose  of  determining  the  effect  of  sonar 
performance  on  the  accomplishment  of  a mission.  The  selection 
of  the  functions  to  include  in  the  pilot  version  of  MEP 
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represent  an  a priori  judgment  of  the  factors  relevant  to  its 
purpose.  For  example,  the  ship's  galley  is  not  included  in 
MEP  because  the  crew's  diet  is  not  considered  relevant  to  the 
ASW  effectiveness  of  the  ship.  Inter-ship  communication  is 
included  because  it  is  clearly  relevant  to  the  effectiveness 
of  the  defensive  screen.  Each  functional  area  is  simulated 
in  MEP  by  a separate  deck,  e.g.,  the  tactical  decision  func- 
tion by  the  CO  deck,  the  steering  of  a unit  by  the  PI  deck, 
etc. 

Each  deck  carries  out  its  function  for  each  unit 
currently  active  at  each  time  step  during  the  course  of  the 
action.  Thus,  the  CO  deck  successively  handles  the  decision 
making  of  the  destroyer  commanding  officer,  the  aircraft  pilot, 
etc.  On  some  units,  each  function  would  be  performed  by  dif- 
ferent men  or  groups  of  men  and  their  associated  equipment, 
while  on  other  units  several  functions  would  be  performed  by 
one  man.  For  example,  on  an  aircraft  the  functions  simulated 
by  the  CO  and  PI  decks  would  be  performed  by  the  pilot. 

The  success  of  MEP  depends  critically  on  the  functions 
chosen  to  be  simulated.  It  has  been  carefully  organized  into 
program  modules  or  decks  so  that  if  the  testing  phase  shows  that 
a relevant  function  has  been  omitted,  a deck  can  be  added  with- 
out serious  consequences  to  the  existing  decks.  The  current 
version  of  MEP  will  be  designated  the  pilot  version  until  tests 
demonstrate  the  validity  of  the  simulation. 

The  simulation  is  controlled  by  an  executive  program 
(the  EK  deck)  which  advances  time  from  T.MIN  to  T.MAX  in  incre- 
ments of  AT  hereafter  called  D.T  (these  parameters  are  input 
and  remain  constant  during  a run) . During  the  course  of  the 
action,  the  information  generated  during  the  previous  time 
interval  of  length  D.T  forms  the  basis  for  the  decisions  at  time 
T which  determine  the  actions  during  the  following  time  inter- 
val. This  "time-step"  organization  of  the  simulation  is  a 
consequence  of  the  fact  that  tactical  doctrine  has  not  been 
written  into  the  program.  It  is  not  possible  to  advance  the 
simulation  on  an  "event-store"  basis  because  the  program  cannot 
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predict  what  the  next  event  will  be. 

Tactical  doctrine  is  input  to  the  program  in  the 
form  of  conditional  statements  (see  Appendix  A) . These  state 
that  if  a unit  is  in  a particular  operational  phase  and  the 
specified  information  is  reported  by  the  sensors,  then  certain 
actions  will  be  initiated.  At  each  step  of  D.T,  the  program 
must  discover  which  information  specification  is  satisfied  in 
order  to  initiate  a course  of  action. 

A consequence  of  this  time-step  organization  is  that 
actions  can  only  be  initiated  at  values  of  time  that  are  multi- 
ples of  D.T.  For  example,  if  input  sets  D.T  to  a value  of  30  second s^ 
then  it  is  being  assumed  that  the  exact  moment  an  action  is 
initiated  is  significant  only  within  plus  or  minus  15  seconds 
(an  assua?>tion  which  would  probably  be  true  ,in  a scenario  in- 
volving conventional  submarines,  but  false  if  nuclear  boats 
were  involved).  The  valueofD.T  assigned  determines  the  cost  of  a 
run  so  that  it  is  inportant  to  establish  the  feasible  range 
of  values  for  it  versus  the  types  of  scenarios  of  interest. 
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SECTION  II 


I 


SIMULATION  MODEL 


The  pilot  version  of  MEP  simulates  nine  functional 
areas.  Each  of  these  areas  is  simulated  by  a separate  deck: 

Deck  Function 

AS  A/s  Officer,  A/D  equipment  and  operator 
CE  CIC  Evaluation  Officer,  communication,  report  evaluation 
CO  Commanding  Officer,  tactical  decisions  and  doctrine 
FO  Firing  Petty  Officer,  v?eapon  processing 
GL  Communication  Region:  CI.NET,  communication  between 

decks.  Status  Region:  time  parameters,  environmental 

data 

LO  Lookout,  visual  reports 

PI  Pilot,  steering  and  propulsion 

SO  Sonar  set  and  operator,  sonar  reports 
SU  Sonar  Supervisor,  sonar  operating  procedures 

Each  of  these  decks  depends  on  the  other  decks  as 
shown  in  Figure  2-1.  Communication  between  decks  is  accomplished 
by  lists  of  information  in  the  communication  region  of  the  GL 
deck  (see  Appendix  C) . These  lists  are  shown  as  arrows  in 
Figure  2-1.  They  have  names  of  the  form  XX.. YY  where  deck  XX 
produces  the  information  in  the  list  for  use  by  deck  YY,  e.g., 
CE..C0  is  a list  of  information  from  the  CE  deck  to  the  CO 
deck.  CI.NET  is  used  for  inter-ship  communication.  The  nine 
decks  listed  above  have  counterparts  in  the  real  world.  The 
following  six  decks  do  not,  but  perfprn  various  data  processing 
and  control  functions: 

Deck  Function 
DB  Debugging  routines 

EX  Executive  control  program 
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FIGURE  2-1.  "MEP"  INFORMATION  FLOW 
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Deck  Function  (contd) 

FN  Mathematical  function  library  and  list  processing 

routines 

IN  Input  data  processing  program 

10  Input-output  subroutines 

PP  Post-processing  program 

In  the  following  section  (Section  III)  there  are  deck 
descriptions  which  are  meant  for  the  reader  with  a computer 
programming  background.  In  this  section,  some  aspects  of  the 
MEP  model  are  discussed  in  non-programming  language.  However, 
it  must  be  stressed  that  this  results  in  some  circumlocution 
and  loss  of  precision.  In  the  final  analysis,  the  MEP  model 
is  the  program  listing  for  GL  and  eight  decks  shown  in  Figure 
2-1.  This  listing  is  approximately  400  pages  long  so  that 
it  is  not  practical  to  include  it  in  this  report. 

A.  INTER- SHIP  COMMUNICATION 

Communication  between  units  is  simulated  in  the  CE 
and  GL  decks.  The  processing  is  done  by  the  CE  deck,  and  the 
messages  are  in  lists  which  make  up  CI.NET  in  the  GL  deck. 

When  a CO  decides  to  send  a message,  it  is  given  to  the  CE  deck. 
For  a given  time  interval,  W.LIST  will  have  all  the  messages 
that  are  waiting  for  transmission  to  other  units.  Before  the 
CO  deck  processes  all  units  currently  active  for  the  next  time 
interval,  the  CE  deck  processes  the  lists  which  make  up  CI.NET. 

CI.NET  contains  the  acknowledged  messages  (A. LIST) , 
the  messages  being  transmitted  (C.LIST),  and  the  messages  wait- 
ing for  transmission  (W.LIST).  The  CE  deck  processes  CI.NET 
in  three  steps.  First,  it  erases  A. LIST  (messages  in  this 
list  at  this  time  will  have  been  delivered  during  the  previous 
time  interval).  Next,  the  CE  deck  examines  the  messages  in 
C.LIST.  Each  message  requires  a length  of  time  to  be  trans- 
mitted which  is  a function  of  its  length.  If  a message  has 
been  in  C.LIST  for  the  required  length  of  time,  it  is  taken 
out  of  C.LIST  and  put  in  A. LIST  so  that  it  will  be  available 
during  the  next  time  interval.  Finally,  the  CE  deck  fills 
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C.LIST  with  messages  from  the  W.LIST.  The  number  of  messages 
which  can  be  in  C.LIST  simultaneously  is  controlled  by  input. 

A message  in  W.LIST  must  be  transmitted,  i.e.,  put  into  C.LIST 
within  a specified  time  which  is  a function  of  its  priority 
or  it  is  erased. 

This  model  allows  various  communication  phenomena 
to  be  simulated.  If  the  number  of  transmission  channels  in 
C.LIST  is  set  to  zero,  no  inter-ship  communication  can  take 
place,  and  each  CO  will  have  to  rely  on  doctrine  and  his  own 
sensors.  If  the  number  of  transmission  channels  is  small, 
e.g. , one  or  two,  a communication  jam  could  occur  if  the 
prosecution  of  an  attack  depended  on  a team  effort  of  several 
units. 

B.  A COURSE  MANEUVER 

Course  maneuvers  result  from  a CO*s  tactical  decision. 
For  the  sake  of  concreteness,  assume  that  a submarine's  passive 
sonar  has  picked  up  the  noise  of  heavy  screws  and  the  CO  decides 
to  head  directly  for  the  source  of  this  noise.  This  is  a common 
initial  maneuver  for  a submarine  whose  mission  is  anti-shipping. 
This  course  would  be  held  until  the  submarine  obtains  enough 
information  to  estimate  the  course  of  its  target.  To  carry  out 
this  maneuver  the  CO  deck  constructs  a list  called  CO.. PI  which 
gives  orders  to  the  PI  deck.  This  list  also  contains  the  sonar 
report  on  the  target  toward  which  the  PI  deck  is  to  steer  the 
submarine. 

The  function  of  the  PI  deck  is  to  advance  a unit 
along  its  track.  In  this  example  it  would  advance  the  sub- 
marine and  turn  towards  the  true  bearing  given  in  the  report 
which  is  part  of  the  CO.. PI  list.  Let  this  desired  true  bear- 
ing be  030  and  assume  that  the  current  heading  of  the  submarine 
is  150,  then  the  PI  deck  would  turn  the  submarine  to  port. 
However,  D.T  (the  basic  time-step  for  the  situation)  may  be  too 
small  for  the  submarine  to  accomplish  a 120-degree  turn  to 
port  within  one  time  interval.  Maximum  turn  rates  for  each 
type  of  unit  are  controlled  by  a table  in  the  PI  deck.  If 


2-4 


WPll-7-41010 


this  table  limits  the  submarine  to  a 90  degree  turn  for  one 
time-step,  then  the  PI  deck  would  turn  the  submarine  90  de- 
grees to  port  and  it  would  be  on  a heading  of  060.  In  the 
position-course-speed  data  for  the  submarine,  the  PI  deck 
would  record  the  current  course  maneuver  and  a desired  course 
heading  of  030.  Assuming  that  information  does  not  develop 
which  would  cause  the  CO  to  order  a different  course  maneuver, 
the  PI  deck  would  continue  the  current  maneuver  during  the 
next  time  interval  and  complete  the  turn  to  a heading  of  030. 

C.  INITIATING  AN  ATTACK 

Initiating  an  attack  is  a CD’s  tactical  decision 
which  is  carried  out  by  the  A/S  officer.  To  initiate  the 
attack,  the  CO  constructs  a list  called  CO. .AS  which  gives 
orders  to  the  AS  deck.  The  functions  of  the  AS  deck  are  to 
conn  the  attack  and  determine  time  to  fire. 

The  A/S  officer  gets  the  latest  report  on  the  target 
from  the  CE  and  constructs  the  AS.. PI  list,  specifying  a 
collision  course  confuted  from  the  data  in  the  last  report 
of  the  target.  An  AS..F0  list  is  constructed  that  orders 
the  firing  petty  officer  to  begin  weapon  preparation, 
fire  is  computed  by  the  A/S  officer.  This  time  is  based  on 
target  range  and  range  rate  and  the  firing  range  of  the  weapon. 
The  target  data  is  obtained  from  the  last  report  on  the  target, 
and  the  weapon  data  is  obtained  from  a list  produced  by  the  FO 
deck.  This  list  is  constructed  from  tables  in  the  FO  deck. 

If  the  time  to  fire  computed  by  the  A/S  officer  falls 
within  the  next  time  step,  the  weapon  is  launched.  Otherwise, 
no  weapon  is  fired  and  the  calculation  must  be  repeated  at  the 
end  of  the  next  time  step. 

The  model  allows  various  features  of  an  attack 
situation  to  be  simulated.  A weapons  store  is  maintained  for 
each  unit  that  can  initiate  an  attack.  This  store  is  reduced 
every  time  a weapon  is  fired,  and  updated  when  weapons  are 
returned  as,  for  example,  when  an  attack  is  called  off. 
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Thus  it  is  possible  for  a unit  to  exhaust  his  supply  of  weapons. 
Time  to  fire  is  based  on  target  reports  and,  thus,  target  report 
inaccuracies  can  influence  both  the  initial  decision  to  fire  and 
the  success  or  failure  of  the  weapon  launch. 

D.  PASSIVE  SONAR  REPORT 

The  sonar  set  output  produced  by  the  SO  deck  is  a 
list  of  "reports"  called  the  SO..CE  list.  For  a sub  operating 
in  the  passive  mode,  both  noise  and  echo  ranging  pings  could 
be  part  of  the  sonar  set  output.  A passive  sonar  "report"  which 
describes  the  noise  picked  up  from  a convoy  ship  would  contain  a 
noise  level  index,  and  information  about  the  noise  source  such  as 
true  bearing,  bearing  drift,  and  target  speed.  The  noise  level  vs. 
range  tables  are  in  the  SO  deck.  For  each  type  of  sonar  set  there 
there  are  tables  for  above- layer  and  below- layer  reception.  A 
passive  sonar  "report"  which  describes  echo  ranging  ping  recep- 
tion would  be  Similar  to  a noise  report,  except  that  it  would 
have  a time  associated  with  it,  a code  designating  long  or  short 
scale,  and  different  tables  would  be  used  to  get  the  signal  level 
level  index. 
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SECTION  III 
PROGRAM  ORGANIZATION 


MEP  is  written  in  MAP,  the  assembly  language  of  the 
IBJOB  monitor  which  runs  under  IBSYS  on  the  IBm  7094  computer. 
MEP  is  divided  into  15  decks,  9 of  which  have  counterparts  in 
the  real  world  and  are  described  in  Appendix  B.  A dynamic 
storage  allocation  technique  is  used  which  is  similar  to  the 

if 

one  used  in  LISP  . 

A.  LIST  STRUCTURE  DIAGRAMS 

A list  structure  diagram  consists  of  rectangular  sym- 
bols which  represent  storage  cells  and  arrows.  As  in  LISP,  the 
left  half  of  a symbol  represents  the  address  part  of  a word  in 
storage,  and  the  right  half  represents  the  decrement  part: 


I " I ° 1 


1 


In  this  example,  the  address  of  P is  in  the  address  part  of  the 
word  in  symbolic  location  X,  the  address  of  Q in  the  decrement. 

An  equivalent  statement  is  that  the  address  part  of  the  word 
in  symbolic  location  X "points”  to  P,  the  decrement  part  "points" 
to  Q.  If  the  word  in  location  P is  a continuation  of  the  list 
structure  as  shown  below: 


X ' “ — — 

McCarthy,  Abrahams,  Edward,  Hatt,  and  Levin,  "LISP  1.5  Program- 
mer's Manual",  MIP  Press,  Cambridge,  Mass.,  1962 
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then  P would  not  be  written  in  the  symbol  for  the  word  in  lo- 
cation X,  but  would  be  replaced  by  an  arrow  drawn  to  the  symbol 
which  represents  the  list  structure  word  in  location  P.  As  in 
LISP,  if  the  address  or  decrement  part  of  a word  is  zero,  it  is 
said  to  point  to  NIL.  In  a list  structure  diagram  this  is  in- 
dicated by  a diagonal  line  drawn  through  that  part  of  the 
symbol: 


In  this  example  the  decrement  parts  of  the  words  in  locations 
P and  Q point  to  NIL.  This  indicates  that  the  decrement  parts 
of  these  words  do  not  lead  to  further  list  structure. 

B.  LIST  CONSTRUCTION 

At  the  start  of  each  run  the  storage  area  in  the  GL 
deck  called  LIST. . is  linked  into  one  list  called  the  "free 
storage  list"  and  the  address  part  of  the  word  in  location  FLR 
is  set  to  point  to  the  first  word  in  this  list: 


FLR 


1 
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A routine  which  requires  a word  to  construct  a list 
obtains  this  word  from  the  free  storage  list  by  using  the  word 
to  which  FLR  points,  and  setting  FLR  to  point  to  the  next  word 
in  the  free  storage  list; 


FLR 


When  a list  structure  word  has  served  its  purpose, 
it  is  returned  to  the  free  storage  list  by  making  it  point  to 
the  same  word  that  FLR  currently  points  to,  and  then  setting 
FLR  to  point  to  the  word  being  returned: 


FLR 


I [ — I 


1:^ 

1 — H 

XI  _ _ 

-hJ 

1 f 

\ 

WORD  BEING 
RETURNED 

These  procedures  allow  storage  for  list  structure  to  be  allo- 
cated dynamically  during  a run.  At  the  time  a routine  needs 
to  build  up  a list  structure,  it  obtains  the  words  for  this 
structure  from  the  free  storage  list.  When  the  list  struc- 
ture is  no  longer  needed,  the  words  from  which  it  is  construc- 
ted are  returned  to  the  free  storage  list  for  use  by  another 
routine. 
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List  structure  is  used  to  link  data  blocks  vhich  con- 
tain the  information  in  a list.  A data  block  is  a group  of 
four  consecutive  words  in  storage.  All  data  blocks  are  in  a 
storage  area  called  DATA.,  in  the  GL  deck.  At  the  start  of 
a run  the  first  words  in  each  of  these  blocks  are  linked 
together  in  the  same  way  as  the  free  storage  list.  The 
word  in  symbolic  location  FBR  is  set  to  point  to  the  first 
block  in  this  list.  Data  blocks  are  obtained  and  returned  in 
the  same  manner  as  described  above.  For  example,  W.LIST  con- 
tains the  messages  waiting  for  transmission  during  the  next 
time  interval.  Assume  that  two  messages  are  in  W.LIST.  Then, 
in  diagram  form: 


W.  LI£T 


I LIST  STRUCTURE 
r IN  LIST-  • 


I DATA  BLOCKS 
r IN  DATA*  • 


Each  data  block  would  contain  the  information  associated  with 
one  of  the  messages  waiting  for  transmission.  Assume  that 
another  CO  decides  to  send  a message,  then  a word  is  obtained 
from  LIST. . via  FLR,  a data  block  is  obtained  from  DATA. . via 
FDB,  and  the  message  is  added  to  W.LIST: 


W.LIST 
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When  these  messages  have  served  their  purpose,  the  list  struc- 
ture and  data  blocks  to  which  the  address  part  of  W.LIST  points 
are  returned  to  LIST. . and  DATA. . so  that  they  may  be  used  by 
other  routines. 

C.  LIST  PROCESSING  SUBROUTINES 

The  decks  described  in  Appendix  B process  the  informa- 
tion in  various  lists,  and  either  produce  other  lists  or  alter 
the  information  in  existing  lists.  The  FN  deck  contains  sub- 
routines which  are  used  for  the  creation  or  modification  of 
lists.  The  principles  on  which  these  subroutines  are  based 
have  been  explained  above.  Two  basic  operations  occur  fre- 
quently in  locating  and  processing  information  in  a list: 

CAR  and  CDR. 

CAR,  the  contents  of  the  address  register,  is  used 
in  a declarative  sense  in  the  deck  descriptions  in  Appendix  B. 
The  statement  "CAR(X)  is  the  list  Y"  means  that  the  address 
part  of  the  word  in  symbolic  location  X points  to  the  list  struc 
ture  which  is  the  list  Y.  CDR  has  an  analogous  meaning  for  the 
decrement.  In  the  program,  CAR  and  CDR  have  an  imperative  force 
They  are  macro  instructions  which  expand  as  follows: 

CAR:  PAC  ,7  CDR:  PDC  ,7 

CAL  0,7  CAL  0,7 

If  CAR(X)  is  Y,  then  the  following  sequence  of  instructions  will 
get  the  first  word  of  the  list  structure  that  is  Y: 

CAL  X 
CAR 

Thus,  if  the  location  of  the  first  word  of  a list  is  known,  any 
part  of  the  list  can  be  located  with  the  appropriate  sequence 
of  CAR’s  and  CDR's. 
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D.  UNIT  DESCRIPTIONS 

U.LIST  is  a list  which  describes  all  the  units 
currently  active.  Information  in  this  list  is  used  by  all 
the  decks  described  in  Appendix  B.  The  IN  deck  constructs 
U.LIST  from  the  information  supplied  by  the  FOEiCES...  section 
of  the  input  data.  The  top  level  of  U.LIST  links  all  of  these 
descriptions  into  one  list.  If  a unit  has  no  sonar  or  weapons, 
e.g.,  a convoy  ship,  or  its  sonar  and  weapons  are  irrelevant 
to  a scenario,  the  IN  deck  constructs  a unit  description  as 
shown  in  Figure  3-1  for  U.LIST.  The  position  and  course  data 
blocks  are  for  time  T.MIN,  the  beginning  of  the  scenario. 

SET. PI  adds  another  pair  of  data  blocks  so  that  all  decks  have 
position  and  course  data  for  T-D.T  and  T available  during  their 
processing.  The  unit  description  is  then  as  shown  in  Figure 
3-2.  If  a unit  has  a sonar  a*nd  weapons,  the  IN  deck  constructs 
the  description  shown  in  Figure  3-3.  This  list  has  provision 
for  sonar  set  status  and  weapon  data. 

E.  FLOW  OF  CONTROL 

The  EX  deck  is  the  executive  control  program  (see 
flowchart  in  Figure  3-4) . It  calls  IN  to  read  the  input  data 
for  a scenario  and  set  up  U.LIST  descriptions  for  the  units 
involved.  Time  is  set  to  T.MIN  and  the  initialization  entries 
in  each  deck  are  called.  This  completes  the  processing  neces- 
sary to  begin  the  action. 

The  CE.NET  call  begins  the  program  loop  which  is 
executed  for  each  time-step  during  the  course  of  the  action. 
This  call  causes  the  CE  deck  to  process  the  messages  in  CI.NET 
CO. PRO  begins  a decision-action  loop  which  processes  all  the 

units  currently  active  (see  the  CO  deck  description  in  Appendix 
B) . T is  then  advanced  to  T+D.T  and  compared  to  T.MAX.  If  the 
action  is  over,  the  PP  deck  is  called  to  perform  the  post- 
processing analysis  of  the  action.  If  the  action  is  not  over, 
the  PI  deck  updates  all  position  and  course  data  blocks  in 
U.LIST  and  control  returns  to  the  CE.NET  call  to  continue  the 
action. 
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FIGURE  3-1.  UNIT  DESCRIPTION  (WITH  NO  SONAR  OR  WEAPONS,  BEFORE  PROCESSING) 


DESCRIPTION  (WITH  NO  SONAR  OR  WEAPCWS , DURING  PROCESSING) 


WEAPONS  BEING  PREPARED  POR  FIRING 


FIGURE  3-3.  UNIT  DESCRIPTION  (WITH  SONAR  AND  WEAPONS,  BEFORE  PROCESSING) 
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APPENDIX  A 

TACTICAL  CONTROL  LANGUAGE 


The  current  dictionary  for  the  MEP  tactical  control 
language  (TCL)  is  given  in  this  appendix.  The  phrases  in 
TCL  were  abstracted  from  an  ORE  exercise  of  some  complexit5r*. 

Each  of  these  phrases  is  represented  by  an  abbreviation  of  at 
most  4 characters  to  facilitate  the  processing  of  TCL  state- 
ments by  the  IN  deck.  The  syntax  of  TCL  is  best  shown  by 
examples.  Assuming  that  a submarine  CO  would  base  an  action 
on  the  fact  that  his  passive  sonar  was  picking  up  echo  rang- 
ing pings  off  the  bow,  the  TCL  statement  for  the  information 
specification  would  be:  "ERP-BOW".  The  hyphen  between  the 

two  TCL  abbreviations  is  a connective.  For  this  specification 
to  be  satisfied,  the  sonar  must  not  only  be  picking  up  echo- 
ranging pings  (ERP) , but  they  must  also  be  off  the  bow  (BOW). 

This  specification  could  be  made  more  precise  if  desired  by 
adding  other  terms  from  the  TCL  dictionary  which  are  appropriate, 
e.g.,  "ERP-LSC-BOW",  "ERP-LSC-BOW-RC" , etc.  A comma  is  used 
to  separate  two  specifications  for  the  same  source  of  informa- 
tion, e.g.  , "ERP-PBM,ERP-SBM"  specifies  that  echo-ranging  pings 
must  be  picked  up  off  both  the  port  beam  (PBM)  and  the  star- 
board beam  (SBM)  . Blanks  are  used  to  separate  specifications 
for  different  sources,  e.g.,  "ERP-BOW  DD-STN"  specifies  that 
the  sonar  must  be  picking  up  echo-ranging  pings  off  the  bow  and 
a destroyer  must  be  sighted  off  the  stern  for  this  information 
specification  to  be  satisfied. 

The  following  dictionary  gives  the  TCL  abbreviations 
used  on  input  data  cards,  the  TCL  octal  code  used  internally, 
and  the  meaning  of  each  phrase  currently  in  this  language. 


^ “ “ “ 

Nagelhout,  Savage,  and  Kistler,  "Submarine  Attacks:  Procedures 

and  Constraints  in  Attacks  on  Surface  Ships  (U)",  SECRET, 
NAVWEPS  Report  No.  8526,  NOTS  TP-3592 
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TCL  Dictionary 


AS  PR 

0402 

Assist  prosecution 

ATRN 

3001 

Attack  turn 

ATTK 

0202 

Attack  phase 

ATV 

1101 

Active  sonar  mode 

BCL 

1461 

Bearing  clear 

BFL 

1462 

Bearing  foul 

BM 

0601 

Off  the  beam,  either  PBM  or  SBM 

BOW 

0602 

Off  the  bow,  RB  -45  to  +45 

CLSN 

3013 

Collision  course 

DC 

5011 

Depth  charge 

DD 

1411 

Destroyer 

DPDN 

1213 

Doppler  down 

DPUP 

1211 

Doppler  up 

EQ 

1001 

Equal 

ERP 

1221 

Echo-ranging  pings 

ETRN 

3002 

Evasive  turn 

EVDE 

0203 

Evade  phase 

EXPN 

5000 

Have  all  been  expended 

FD 

1441 

Flaming  datum 

FIX 

1402 

Fixed  object 

FLT  , 

1403 

Floating  object 

FTC 

5021 

False  target  cannister 

GE 

1002 

Greater  than  or  equal 

GT 

1003 

Greater  than 

HEAD 

3014 

Head  directly  at  (tail  chase) 

HH 

5012 

Hedgehog 

HIT 

1442 

Hit  scored  by  a weapon 

HMT 

5001 

Homing  torpedo 

HOLD 

7077 

Hold 

HSS 

1722 

High-speed  screws 

HV 

1412 

Heavy  (convoy)  ship 

HVS 

1223 

Heavy  screws 
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INT 

1241 

Intensity 

INTP 

3021 

Interpose 

LE 

1004 

Less  than  or  equal 

LEAD 

3012 

Rough  lead  course 

LSC 

1231 

Long  scale 

LSSC 

1202 

Lost  sonar  contact 

LT 

1005 

Less  than 

MBC 

0411 

Maintain  base  course 

MRB 

0632 

Magnitude  of  RB 

MRR 

0623 

Magnitude  of  RR 

MTA 

0642 

Magnitude  of  TA 

MTBR 

0653 

^gnitude  of  TBR 

NE 

1006 

Not  equal 

NODP 

1212 

No  doppler 

NONS 

0421 

Non-submarine  contact 

NOPS 

1220 

Nothing  on  passive  sonar 

NOSC 

1200 

No  sonar  contact 

NOVR 

1400 

No  visual  report 

NWV 

3031 

Narrow  weave 

OFF 

1100 

Sonar  set  is  off 

OTC 

2601 

Tactical  commander  of  the  force 

OUT 

0431 

Out  of  action 

OWN 

1401 

Own  ship 

PBM 

0603 

Off  the  port  beam,  RB  -135  to  -45 

PCRL 

3011 

Pursuit  circle 

PNTR 

0201 

Penetration  phase 

POSS 

0422 

Possible  submarine  contact 

PRSC 

0401 

Prosecute 

PRSS 

0423 

Probable  submarine  contact 

PSCP 

1451 

Periscope  feather 

PSSS 

0424 

Positive  submarine  contact 

PSV 

1102 

Passive  sonar  mode 

\ 


\ I 
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R 

0621 

Horizontal  range 

RB 

0631 

Relative  bearing 

RC 

0611 

Range  closing 

RO 

0613 

Range  opening 

RR 

0622 

Range  rate 

RS 

0612 

Range  steady 

SBM 

0604 

Off  the  starboard  beam,  RB  45  to 

135 

SC 

1201 

Sonar  contact 

SCHl 

4001 

Sonar  procedure,  Search  Doctrine 

1 

SCH2 

4002 

Sonar  procedure.  Search  Doctrine 

2 

SCH3 

4003 

Sonar  procedure.  Search  Doctrine 

3 

SOA 

0412 

Speed  of  advance 

SRCH 

0200 

Search  phase 

SRT 

5002 

Straight  running  torpedo 

SS 

1421 

Submarine 

SSC 

1232 

Short  scale 

STM 

0605 

Off  the  stem,  MRB  135  to  180 

TA 

0641 

Target  angle 

TB 

0651 

True  bearing 

TBR 

0652 

True  bearing  rate  or  drift 

TRCK 

0204 

Track  phase 

VP 

1431 

Landbased  aircraft 

WA 

5013 

Weapon  A 

WWV 

3032 

Wide  weave 

★★★★ 

7000 

Irrelevant 
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Deck : AS 

Function:  A/S  Officer 


Entry ; AS . ATK 

Processes;  CO. .AS,  CE. .AS 
Produces:  AS..CE,  AS..FO,  AS.. PI 


This  deck  sinoilates  the  activities  of  the  A/S  officer 
on  a unit.  For  a unit  which  is  not  in  the  attack  phase,  this 
consists  of  a call  to  FO.STO  to  erase  the  list  of  weapons  in 
preparation  for  this  unit. 

For  a unit  which  is  in  the  attack  phase,  the  AS  deck 
conns  the  attack.  CE.ATK  is  called  to  get  the  latest  report 
on  the  target  and  the  pilot  control  list,  CDR(CO..AS)  is  modi- 
fied for  a collision  course.  AS.. PI  is  constructed  and  PI. ATK 
is  called  to  advance  own  ship.  If  own  ship  is  not  the  command 
ship,  FO.STO  is  called  and  this  completes  processing  of  the 
unit  by  the  AS  deck. 

If  own  ship  is  the  command  ship,  the  AS  deck  directs 
weapon  preparation  and  firing.  CAR(CO..AS)  is  a pointer  to 
the  list  of  weapons  which  are  to  be  prepared.  AS..FO  is  con- 
structed from  CO.. AS,  and  FO.PRE  is  called  to  begin  weapon 
preparation.  If  own  ship  has  a target  report  on  its  own  equip- 
ment, the  AS  deck  attempts  to  fire. 

The  list  of  weapons  in  preparation,  in  the  top  level 
of  the  U-LIST,  is  searched.  Each  weapon  data  block  in  this 
list  contains  an  earliest  time  to  fire,  ETTF,  and  a range  to 
fire,  RTF.  For  each  weapon  in  preparation,  the  AS  deck  computes 
a time  to  fire  based  on  range  rate  and  target  range  from  the 
last  target  report.  If  this  time  is  later  than  ETTF,  and  within 
the  next  time  interval,  FO. PNL  is  called  to  fire  the  weapon. 

For  this  call,  AS..FO  indicates  the  weapon  to  be  fired  and  the 
time  to  fire.  Processing  of  the  weapon  list  completes  the 
AS  deck's  functions  for  the  command  ship. 
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Entry : AS . FOM 
Processes:  FO. .AS 
Produces:  AS..CE 


This  entry  is  used  by  the  FO  deck  to  advise  the  A/S 
officer  that  the  stock  of  a weapon  has  been  exhausted.  The 
AS  deck  sends  an  internal  message  to  the  CE  via  AS..CE. 
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Deck:  CE 

Function:  CIC  Evaluation  Officer 

Entry:  CE.ASM 

Processes:  AS..CE 


This  entry  in  the  CE  deck  takes  an  internal  message 
from  the  AS  deck  and  inserts  it  in  I* LIST. 

Entry:  CE.ATK 

Produces:  CE..AS 


This  entry  in  the  CE  deck  supplies  the  latest  report 
on  the  target  being  attacked  to  the  AS  deck. 

Entry:  CE.COM 

Processes:  C0..CE 


This  entry  in  the  CE  deck  takes  a message  in  C0..CE 
which  the  CO  has  ordered  transmitted  to  another  unit  and  puts 
it  in  W.LIST.  It  determines  the  length  of  the  message  and  in- 
serts the  transmission  time  required  in  the  data  block  for  the 
message.  The  priority  (assigned  by  the  CO)  is  used  to  set  the 
maximum  waiting  time. 

Entry:  CE.NET 

Processes:  CI.NET 

This  entry  in  the  CE  deck  processes  the  messages  for 
inter-ship  communication.  A. LIST  is  erased  and  the  transmission 
times  of  the  messages  in  C.LIST  are  updated.  Messages  which 
have  completed  the  required  amount  of  time  in  C.LIST  are  in- 
serted in  A. LIST.  When  this  processing  has  been  completed, 
the  open  channels  in  C.LIST  are  filled  with  messages  selected 
at  random  from  W. List.  Then  the  messages  remaining  in  W.LIST 
are  processed.  If  a message  has  been  waiting  an  excessive  length 
of  time  for  transmission,  it  is  erased. 
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Entry : 
Processes : 
Produces : 


CE.EIPT 

LO. .CE,  SO. ,CE 
CE. .CO 


This  entry  in  the  CE  deck  supplies  information  to 
the  CO  on  which  he  will  base  his  tactical  decisions.  It  is 
the  task  of  this  entry  to  evaluate  the  information  from  the 
sensors  in  LO. .CE  and  SO..CE  before  passing  it  on  to  the  CO 
deck  via  CE..CO.  Before  performing  this  evaluation,  the  CE 
takes  the  internal  messages  for  own  ship  from  I. LIST  and  puts 
them  into  the  appropriate  section  of  M. LIST.  Messages  in 
CI.NET  are  then  sorted  into  two  groups.  The  messages  addressed 
to  own  ship  are  put  into  one  list,  and  those  addressed  to  other 
ships  are  put  into  another  list  to  allow  own  ship  to  monitor 
them.  This  completes  M.LIST  processing.  If  own  ship  is  not 
under  the  control  of  a section  in  the  tactical  decision  table, 
this  will  conclude  the  CE.RPT  processing  for  own  ship.  If  the 
CO  of  own  ship  must  make  a decision,  the  CE  calls  the  LO  and 
SO  decks  to  get  LO..CE  and  SO..CE. 

The  CE  deck  evaluates  the  sonar  reports  in  SO..CE 
under  the  control  of  a limited-entry  decision  table  which  is 
set  up  by  the  CLASSIFICATION  PROCEDURES. . . section  of  the  input 
data.  For  each  report  in  SO. .CE  the  conditions  specified  by 
the  condition  stub  are  evaluated.  The  columns  of  the  mask  and 
table  matrices  are  then  tested  (from  left  to  right)  to  deter- 
mine which  decision  rule  is  applicable.  The  action  stub  entries 
of  the  applicable  rule  determine  the  action  taken  by  the  CE. 

The  CE  deck  evaluates  the  visual  reports  in  LO. .CE 
under  the  control  of  tables  in  the  CE  deck.  A table  is  selec- 
ted for  the  type  of  unit  on  which  the  lookout  is  stationed. 

The  quality  of  each  visual  report  is  then  compared  to  the 
appropriate  entry  in  the  table  which  has  been  selected.  This 
entry  gives  the  minimum  quality  for  a report  to  be  given  to 
the  CO. 
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Deck : CO 

Function:  Commanding  Officer 

Entry:  CO. PRO 

Processes:  CE. .CO 

Produces:  CO. .AS,  CO. .CE,  CO. .PI.  and  CO..SU 

This  deck  simulates  the  decision  making  by  the  com- 
manding officer  of  a unit.  It  is  a loop  that  makes  a decision 
and  initiates  action  over  the  units  currently  active  in  U.LIST. 
CAR(UNIT. I)  is  the  list  describing  the  particular  unit  being 
processed  (called  own  ship  below) . 

The  processing  for  each  unit  begins  with  a CALL  to 
CE.RPT  to  get  the  CE. .CO  list.  This  list  contains  the  infor- 
mation on  which  the  CO  will  make  his  decisions:  messages 

(both  internal  messages  to  the  CO  from  his  own  men  and  messages 
on  C1.NET  from  other  units),  sonar  reports,  and  visual  reports. 
Before  making  a decision,  the  CO  processes  the  internal  messages 
and  the  high  priority  messages  on  CI.NET.  Certain  messages, 
e.g. , orders  from  the  OTC,  may  preclude  any  decision  considera- 
tions by  the  CO  at  the  moment. 

If  the  CO' s decision  for  the  next  time  interval  is  to 
be  based  on  doctrine,  the  tactical  decision  table  is  processed. 
IDC  (in  the  description  data  block)  locates  the  first  line  in 
own  ship's  section  of  the  tactical  decision  table.  The  first 
item  in  each  line  of  this  table  is  the  operational  phase  to 
which  the  line  applies,  e.g.  , SRCH,  ATTK,  etc.  PHASE  (in  the 
description  data  block)  has  the  current  operational  phase  for 
own  ship.  This  is  matched  with  the  first  item  in  each  line 
until  a line  is  found  that  is  applicable.  If  no  such  line  is 
found,  the  CO  maintains  the  status  quo. 

Each  line  in  the  tactical  decision  table  is  divided 
into  an  information  segment  and  an  action  segment.  If  the 
line  is  applicable  to  the  current  operational  phase  of  own 
ship,  the  information  segment  is  scanned.  If  the  information 
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specified  by  this  segment  is  a subset  of  the  information  in 
the  CE..CO,  then  this  line  is  satisfied  and  the  action  segment 
is  scanned  to  create  CO. .AS,  CO. .CE,  CO. .PI,  and  CO..SU  which 
are  the  orders  to  the  A/S  officer,  the  CIC  evaluation  officer, 
the  pilot,  and  the  sonar  supervisor. 

}/ 

The  last  item  in  the  action  segment  of  a line  is 
the  operational  phase  to  be  initiated.  After  this  has  been 
stored  in  PHASE  the  CO  calls  CE.COM  (to  send  a message) , PI.ADV 
(to  advance  the  position  of  own  ship,  if  own  ship  is  not  in 
the  ATTK  phase) , AS.ATK  (to  conn  the  attack,  if  own  ship  is 
in  the  ATTK  phase),  and  SU.DOC  (to  set  sonar  operating  pro- 
cedures). After  these  calls,  own  ship  will  have  been  advanced 
to  the  point  along  its  track  associated  with  time  T+D.T  . The 
information  generated  because  of  this  motion  will  not  have 
been  computed  at  this  point  in  the  program  because  this  cannot 
be  done  until  all  units  have  been  advanced. 

After  these  actions  have  been  initiated,  the  list 
structure  words  and  data  blocks  no  longer  needed  are  returned 
to  LIST.,  and  DATA.,  in  GL.  This  completes  the  processing  of 
a unit.  IF  U.LIST  is  exhausted,  control  returns  to  the  EX 
deck.  If  not,  control  returns  to  the  beginning  of  the  decision- 
action  loop  and  the  next  unit  in  U.LIST  is  processed. 
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Deck : FO 

Function:  Firing  Officer 


Entry:  FO.PNL 

Processes:  AS..FO 


This  entry  simulates  the  firing  of  a weapon  by  the 
unit's  firing  petty  officer.  AS..FO  indicates  the  weapon  to 
be  fired  and  the  time  to  fire.  The  FO  deck  deletes  the  weapon 
data  block  from  the  list  of  weapons  in  preparation  in  the  top 
level  of  the  U.LIST  . Provision  has  been  made  for  regarding 
the  weapon  which  has  just  been  fired  as  a new  unit,  and  enter- 
ing its  description  into  the  U.LIST  as  an  addition  to  the 
lists  of  units  currently  active. 

Entry:  FO. PRE 

Processes:  AS..FO 

Produces:  FO..AS 

This  entry  simulates  the  weapon  preparation  activities 
of  the  firing  petty  officer.  AS..FO  indicates  the  weapon  to  be 
readied.  If  the  desired  weapon  is  already  being  prepared,  the 
firing  officer's  processing  is  complete.  If  preparation  has 
not  already  been  initiated,  the  firing  officer  checks  the  weapon 
store  in  the  U.LIST  description  for  own  ship.  If  the  stock  of 
this  weapon  has  been  exhausted,  the  firing  officer  sends  an  in- 
ternal message  to  the  A/S  officer  via  FO..AS,  and  the  firing 
officer's  processing  is  complete. 

If  neither  of  the  above  conditions  exist,  the  firing 
officer  reduces  the  stock  of  this  weapon  and  constructs  a 
weapon  data  block.  This  data  block  contains  the  weapon  desig- 
nation, firing  range  and  an  earliest  time  to  fire.  The  firing 
range  and  weapon  preparation  time  are  obtained  from  tables 
internal  to  the  FO  deck.  The  weapon  data  block  is  inserted  into 
the  list  of  weapons  in  preparation,  and  this  completes 
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processing  of  the  unit  by  the  FO  deck. 

Entry:  FO.STO 

This  entry  simulates  the  activities  of  the  firing 
petty  officer  when  an  attack  is  called  off.  The  list  of 
j weapons  in  preparation  is  erased  and  the  weapon  store  is  up- 

• dated. 
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Deck:  LO 

Function:  Lookout 

Entry:  LO.RPT 

Produces:  LO..CE 

This  deck  simulates  the  action  of  a lookout  and  pro- 
duces the  visual  reports  given  to  the  CE  deck  for  evaluation. 

If  own  ship  is  below  the  depth  at  which  a lookout  can  see  other 
units,  LO. .CE  is  cleared  and  control  returns  to  the  CE  deck. 

If  it  is  possible  for  the  lookout  to  see  other  units, 
then  height  and  time  of  day  factors  are  found  by  interpolation 
in  tables  in  the  LO  deck.  The  range  the  lookout  can  see  is  a 
product  of  these  factors  and  the  range  of  visibility  (an  input 
parameter) . 

After  the  range  that  the  lookout  can  see  has  been 
found,  each  unit  in  U.LIST  is  processed  (except  for  own  ship) 
to  determine  if  the  unit  is  visible  to  the  lookout.  The  range 
to  each  unit  is  divided  by  the  range  the  lookout  can  see  to 
obtain  a normalized  range  which  is  used  as  an  argument  for 
interpolation  purposes.  A table  is  selected  from  those  in  the 
LO  deck  for  the  type  of  unit  being  sighted  and  the  conditions 
which  currently  exist,  e.g.  , whether  the  sun  is  up  or  not, 
whether  the  anit  has  darkened  ship  or  not,  etc.  If  it  is  a 
periscope  or  periscope  feather  which  is  being  sighted,  the 
sea  state  (an  input  parameter)  is  used  to  select  a table. 
Interpolation  in  the  table  selected  yields  the  "quality"  of 
the  sighting.  If  it  is  zero,  no  visual  report  is  created  for 
this  unit.  If  it  is  not  zero,  a visual  report  is  inserted  in 
LO. .CE  for  evaluation  by  the  CE  deck. 
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Deck : PI 

Function:  Pilot 

Entry:  PI.ADT 

This  entry  in  the  PI  deck  updates  the  position  and 
course  data  in  U.LIST  for  all  units  currently  active.  The 
track  of  a unit  is  from  P3  to  P2  to  PI.  The  PI.ADT  entry  de- 
letes the  current  P3  data  blocks  for  position,  course,  and  speed 
data  so  that  the  current  P2  blocks  become  the  next  P3  blocks 
because  of  their  position  in  the  list  structure.  Since  the 
current  PI  data  blocks  follow  these  blocks,  they  become  the 
next  P2  blocks.  When  this  processing  has  been  conqjleted, 
there  are  no  PI  data  blocks.  These  will  be  supplied  by  the 
entries  described  below  as  each  unit  is  advanced  from  P2  at 
time  T to  PI  at  time  T+D.T  . 

Entries:  PI.ADV  and  PI.ATK 

Process:  CO. . PI  or  AS.. PI 

Both  of  these  entries  in  the  PI  deck  advance  the 
unit  described  by  CAR(UNIT.I).  PI.ADV  assumes  that  CO.. PI 
is  the  pilot  control  list,  and  PI.ATK  assuxnes  that  AS..  PI  is 
the  pilot  control  list.  This  list  contains  data  blocks  which 
specify  the  course,  sptad,  and  depth  or  altitude  (if  own  ship 
is  not  a surface  ship)  maneuvers  desired.  If  these  maneuvers 
are  the  same  as  the  current  maneuver  given  in  the  P2  data 
blocks,  then  they  are  continued.  If  not,  new  maneuvers  are 
initiated.  After  the  maneuvers  have  been  determined,  the  de- 
sired course  heading,  speed,  and  depth  or  altitude  are  computed. 
The  change  in  course  heading  is  limited  to  a value  from  a table 
in  the  PI  deck.  The  limit  depends  on  the  type  of  unit  being 
advanced.  The  desired  horizontal  speed  and  depth  or  altitude 
yield  speeds  and  changes  in  speed  which  are  also  limited  by 
tables  in  the  PI  deck.  The  unit  is  then  advanced  by  construct- 
ing the  PI  data  blocks  in  U.LIST  which  give  the  position. 
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course,  and  speed  data  for  time  T+D.T,  and  the  fuel  supply  for  ) 
the  unit  is  reduced  by  the  amount  required  for  one  step  of  | 
D.T  . I 
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Deck:  SO 

Function:  Sonar  Operation 


Entry : 
Processes : 
Produces : 


SO.RPT 
SU. .SO 

SO. .SU,  SO. .CE 


This  deck  simulates  the  sonar  set  and  operator  on  a 
unit.  When  processing  of  a unit  is  complete,  SO..CE  contains 
all  the  sonar  reports  which  have  occurred  in  the  current  time 
step . 

There  are  five  different  types  of  sonar  reports 
which  could  be  entered  in  the  SO. .CE  list.  For  an  active  mode 
of  operation,  the  sonar  reports  would  include  ping  and  echo  re- 
ports. For  a passive  mode,  they  would  include  noise  and  ping 
glimpse  reports.  The  first  report  in  the  SO. .CE  list  is  always 
a status  report  which  indicates  the  sonar  mode  of  operation. 
Additional  status  reports  in  SO. .CE  would  indicate  a change  in 
sonar  operation  mode.  Echo,  noise  and  ping  glimpse  reports  in- 
clude target  information,  such  as  range  and  bearing,  and  an 
intensity  index.  This  intensity  index  is  computed  by  linear 
interpolation  in  tables  internal  to  the  SO  deck.  There  are  dif- 
ferent sets  of  range  vs.  intensity  index  tables  for  each  report 
type,  sonar  set,  and  target  depth  (above  or  below  the  layer). 

Processing  of  own  ship  begins  by  putting  a pointer  to 
own  ship  in  SU..SO  and  calling  SU.PRC  to  get  the  sonar  control 
list.  This  list  contains  all  console  configurations  required 
by  a particular  procedure  for  the  current  time  interval.  Ping 
and  mode  change  entries  in  this  list  are  used  to  construct  the 
ping  and  status  reports  for  the  SO. .CE  list.  Processing  of  an 
entry  in  the  sonar  control  list  depends  on  the  sonar  mode. 

Active  sonar  processing  is  essentially  a loop  over 
the  U.LIST  to  find  possible  targets.  Ping  glimpse  and  echo 
geometry  are  computed  for  each  possible  target.  If  an  echo 
has  reached  the  sonar  set  within  this  time  step,  an  echo 
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report  is  constructed  and  put  into  the  SO..CE  list. 

Passive  sonar  processing  is  essentially  a loop  over 
the  U.LIST  to  find  possible  noise  and  echo  ranging  ping  sources. 
If  a unit  is  a possible  noise  source,  a noise  report  is  con- 
structed and  put  into  the  SO..CE  list.  If  a unit  is  a possible 
echo-ranging  ping  source,  a pointer  to  the  unit  is  put  in 
SO..SU  and  SU.PRC  is  called  to  get  the  sonar  control  list. 

For  each  ping  entry  in  this  list,  ping  glimpse  geometry  is  com- 
puted. If  a ping  glinqjse  has  occurred  while  own  ship  is  in  the 
passive  mode,  a ping  glimpse  report  is  constructed  and  put  in 
the  SO. .CE  list. 

When  all  the  operations  in  own  ship's  sonar  control 
list  have  been  performed,  the  last  entry  in  the  sonar  control 
list  is  entered  into  the  sonar  status  region  of  the  U.LIST  . 

This  status  data  represents  the  final  status  of  the  sonar  set 
for  this  time  step. 
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Deck:  SU 

Function:  Sonar  Supervisor 

Entry:  SU.CTL 

This  entry  updates  the  sonar  status  region  in  the 
U.LIST  . During  a time  step  the  SO  deck  inserts  sonar  status 
data  corresponding  to  time  T into  the  U.LIST  . At  the  end  of 
a time  step,  the  sonar  status  region  contains  data  for  T-D.T 
and  T.  The  SU  deck  deletes  the  data  for  time  T-D.T  . When  T 
is  advanced  to  the  next  time  step,  the  data  in  the  sonar  status 
region  refers  to  T-D.T  . 

Entry:  SU.DOC 

Processes:  CO..SU 

This  entry  simulates  the  implementation  of  the  CO’s 
decision  to  initiate  a sonar  procedure.  CO..SU  indicates  the 
procedure  to  be  initiated.  If  the  desired  procedure  is  already 
in  effect,  the  processing  of  the  unit  by  the  SU  deck  is  com- 
plete. Otherwise,  the  sonar  status  data  in  the  U.LIST  which 
corresponds  to  time  T is  modified  by  the  supervisor  to  cause 
the  new  procedure  to  go  into  effect  at  the  beginning  of  the 
next  time  step. 

Entry:  SU.PRC 

Processes:  SO..SU 

Produces:  SU..SO 

This  entry  simulates  the  functions  of  the  sonar  super- 
visor for  the  unit  specified  in  SO..SU  . The  task  cf  this  entry 
is  to  produce  the  sonar  control  lists.  The  sonar  control  list 
contains  the  procedural  data  necessary  for  sonar  set  operation. 
Procedural  data  is  obtained  from  tables  internal  to  the  SU  deck. 
Sonar  procedures  are  effective  for  at  least  one  time  interval. 
Sonar  operating  modes,  pulse  spacing,  and  other  operating 
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parameters  are  functions  of  the  procedure  definition  and  not 
the  basic  time  step.  Thus,  provision  has  been  made  for  a 
variety  of  operating  techniques  within  a single  procedure 
spec  if ication. 


WPll-7-41010 


INTERNAL  MESSAGES  TO  OWN  SHIP'S  CO 


W.  LIST  C.  LIST  A.  LIST  I.  LIST 


WPll-7-41010 


CO.  . AS 


